This blog was co-written by Brook Schoenfield.
In the past two weeks, we have seen two big encryption issues arise: key reinstallation attacks, called KRACKs; and “Return of Coppersmith’s Attack,” called ROCA. Many CEOs, CIOs, and CISO/CSOs are asking, as they must, “Are we protected?” and “What’s our exposure?” Security architects are scurrying about to identify reasonable responses that can be presented to anxious executives.
We’ve already looked at KRACKs. How dangerous is ROCA?
Upon reading the Forbes article on ROCA, the first attack (code signatures) did not seem to be that major because operating system certificates typically are not generated on users’ individual machines. “Given a code signing certificate’s public key (which an organization has to publish), an attacker could derive the private key allowing them to sign software impersonating the victim,” said Jake Williams of Rendition InfoSec.
Although Williams’ example is theoretically correct, his statement fails to acknowledge how the major operating system vendors issue certificates. As we shall see from our analysis, only some digitally signed software might suffer from private-key derivation. For several commercial and open-source operating systems, derivation will not be probable, and for others will be impossible.
In case you haven’t read the rest of the analysis, Android is again this week’s security “problem child.”
Android Google Play signing certificates are generated on whatever hardware an application developer happens to own. The key pair are also generated based upon the default Java algorithm in their installation of Java. Surely, some percentage of Android signing certificates use RSA algorithm key pairs smaller than 2,048 bits and are generated from the vulnerable Infineon hardware and software?
It also appears that Apple applications not offered by the Apple Store can be signed with any certificate, including key pairs generated locally. Some small percentage of Apple applications might have key pairs that can be derived via the Infineon chip subject to a ROCA attack.
Because Apple’s Mac OS X doesn’t make use of the Infineon chip for random number generation,[1] we believe the percentage of derivable private keys will be small. Apple development occurs on Apple machines, which use a pseudorandom software algorithm. Only in a corner case would a developer generate the keys outside of Apple’s development system, XCode. Though this is certainly possible, it is not usual, and perhaps quite rare.
Are there other credible attacks? Absolutely. At the current state of key derivation (estimated at 140.8 CPU years), single, targeted derivations are very credible, especially considering adversaries who can afford to apply serious computing time to the derivation.
For attackers who can leverage massive parallel processing or supercomputing resources, the derivation of a targeted private key might be worth the investment. But the attacker first must obtain the public key, which for a number of scenarios will first require gaining a beachhead on the targeted machine.
For attackers who must maximize profits and minimize expenses and investments, key derivation is probably too expensive an operation, unless the return on investment far outweighs the expense of purchasing the computing power and taking the time to perform that single, targeted derivation. This attack occurs one at a time, not as weaponized and global.
Nation-states, cyber armies, and industrial espionage threat actors who aim at specific targets, these are the types of attacks to worry about. For the average consumer who is not a government official, intelligence agency worker, executive, or technical leader of an organization of interest, there is probably little to worry about. Update your firmware (if you can) when it becomes available. But do not change all of your passwords yet again. (Changing passwords provides no protection for this issue.)
If you reuse passwords often, do not construct passwords with lots of character variation, or do not use passphrases, any time is good to change your password strength. The ease of cracking passwords just keeps increasing exponentially. Make your passphrases slow to crack; criminals will move on to easier targets. For those who insist on using poorly constructed passwords, this attack does not decrease your already weak security posture. Weak passwords offer attackers an easy, well-trodden path to success.
For those who are potential targets of a one-off attack powered by significant resources, you should immediately seek a Trusted Platform Module (TPM) firmware update. These users will also need to reprovision the TPM root key pair and any other keys that have been generated by the Infineon chip and its associated random number generator (RNG) library. (More details follow.) Or, potential targets may wish to obtain a different device that is not dependent upon the vulnerable Infineon chip and its RSA key generation library.
For those concerned about McAfee products: McAfee Drive Encryption and McAfee Management of Native Encryption may depend upon an Infineon TPM chip to protect hard disk encryption keys. This not a McAfee vulnerability. Indeed, use of the TPM is a configurable option in McAfee Drive Encryption. If you do not use the “TPM Autoboot” feature, then even if the Infineon chip is present, McAfee Drive Encryption does not use it.
The situation is the same for any product that may take advantage of available TPM protections: A service upon which McAfee software is dependent and over which McAfee has no control has a serious vulnerability that affects the security of the machine upon which McAfee builds its protections.
McAfee customers who must protect data from a tightly targeted attack should seek a TPM firmware update immediately and then reprovision their disk encryption keys. (More details follow.) In any event, like other software that makes use of a root-of-trust like the TPM, we depend upon the TPM to ensure and anchor trust on a machine; that is its purpose and a very strong reason to use it. Hence, McAfee Drive Encryption and McAfee Management of Native Encryption are functioning as designed. (McAfee disk encryption products do not support Google Chromebook computers.)
Let’s take a look at how several major operating systems issue code-signing certificates and why these certificates will likely not be vulnerable to ROCA.
To follow the analysis, remember that ROCA works against the Infineon chip’s RNG. Even if a vulnerable Infineon chip is used, if some other RNG is employed then the ROCA attack is not applicable.
Microsoft
Authentic code certificates, which must be used for Windows digital signatures, are issued only by a limited set of approved certificate authority (CA) vendors. We might imagine that one or more of these vendors have support staff issuing certificates on their laptops, but that is not how it is done. Because the CA business is entirely dependent on the trustworthiness of the private key that is used to sign the root certificate, commercial CA must rigorously defend their root private key, and ensure that it is generated with as much entropy as possible.
We have been directly involved in the implementation of four public key infrastructures (PKIs) at three companies and worked with several more. Although none of these was a commercial CA, a couple were for large enterprises.
Root of trust CA and PKI typically do not depend on a user level or even server machines; they depend on hardware security modules (HSM) for generating and protecting keys and cryptographic functions. HSM are purpose-built appliances to perform cryptographic operations. The few HSM vendors tend to be very jealous of their careful and exacting RNGs. Based upon our investigation, the major HSM vendors build RNGs to exacting standards; these tend to be custom—as a differentiator.
It is certainly possible that these HSMs contain Infineon chips. It is also possible that the vulnerable Infineon RNG is used in some capacity in the HSM vendor’s RNG. But, the HSM RNG would have to pass its entropy failures into the vendor’s RNG, and that is unlikely. HSM RNGs receive a lot of testing and, often, independent certification of randomness.
Our educated guess is that commercial HSMs do not suffer from poor entropy because that is what the HSM business is built upon. Of course, without direct testing, Infineon ROCA susceptibility is still a possibility, though we believe a remote one (except perhaps for Infineon’s own HSM offering, Aurix).
It is very unlikely that a commercial CA that is successful enough to be approved by Microsoft would generate keys on anything less than heavy-duty, purpose-built RNGs, likely an HSM that can also adequately protect the private keys to root certificates.
Thus unless one of Microsoft’s approved CAs is blowing smoke (remembering that Microsoft certify each implementation), the likelihood of a vulnerable Infineon chip behind a Microsoft certified CA is small.
Apple
Apple issues its own Apple Store certificates. Apple would be very foolish to use just any hardware under the control of random employees and contractors for Apple Store key generation. Our educated guess is that they also employ a bank of HSMs to generate keys. After all, Apple must protect private keying material like Fort Knox, or their trust pyramid falls like a house of cards.
Outside the Apple Store, anything is possible. But, Apple’s development platform, XCode, makes it easy to generate keys. It would be a corner case that another piece of hardware and another operating system were used to generate a key pair, though this is certainly possible. XCode uses the operating system’s pseudorandom number generator, /dev/random. The device is a software generator. The Infineon ROCA attack is not relevant to XCode-generated keys.[2]
Linux
Linux makes use of OpenPGP. OpenPGP’s algorithms are specified in RFC 4880, which does not include RSA key pairs. Thus PGP signed software cannot be vulnerable.
Android/Google Play
The key pair for Google Play is generated by the Java key tool, which relies on the local Java installation and whatever cryptography provider is installed. (There is a default reference implementation.) Therefore, it is quite likely that a significant number of Android applications have been signed with the key pair generated by the vulnerable chip and potentially less than or equal to 2,048 bits.
To make matters worse, a Google Play certificate is glued to the single application to which it has been issued and is good for 30 years. How does one ensure that a private key will be safe for 30 years? That’s a couple of epochs in computer time, more in web time. Consider the rate of hardware and software change in the last 30 years. Brook threw away all his floppy disks 10 years ago; he hadn’t inserted one for at least seven years before that.
For a lone application developer without access to a properly managed HSM and security infrastructure, how do they protect their Android private key for three years, much less 30? There are many other ways to attack networks and computers beyond deriving the private key from the public key.
Taking in all of our analysis, the likely set of applications that have derivable private keys via a ROCA attack lie within the Android space. Although a faked signature based upon deriving a private key from a public key generated by the Infineon chip is certainly possible, for most operating systems it is not a credible attack due to mitigating factors in the way commercial organizations build trust with their certificate chains.
That does not mean that locally signed software used within an organization or community is not subject to a ROCA attack; the attack is certainly credible outside the realm of most major operating systems’ signing process. But self-signed certificates for signing software offer no more trust then you can place in the person who has signed the software. Caveat emptor; do not trust software from unreliable sources. That is nothing new.
Apple chose not to use the Infineon TPM chip that it had included in early Intel-powered MacBooks. The chip is no longer included. (See references, at end.)
The second attack reported in the Forbes article, impersonating trusted software that is then validated by an Infineon TPM, does seem credible to me. It might be interesting to identify which computers including the Infineon chip use it as a TPM.
Other credible attack scenarios
Of the other potential attacks, the most worrying will be those targeting a single victim. Once having gained a foothold on a device (in some unspecified manner) for which the root of trust or other cryptographic functions depend upon 2,048-bit or smaller RSA keys generated via Infineon’s RSA library, an attacker can steal the public key of the RSA key pair—if the attacker has access to the public key.[3] Offline, with sufficient computing resources, the attacker can derive the private key. At that point, what the attacker can accomplish is dependent upon the functions for which the private key has been used.
If the vulnerable key pair is used as the device startup (“boot”) root of trust, the attacker can insert software into the boot sequence. That might surrender complete control of the victim’s machine.
If the vulnerable key pair have been used to “seal,” that is, protect secrets in the TPM, then those secrets are compromised. For instance, in the case of Microsoft’s BitLocker disk encryption, the disk encryption key could be gained by the attacker.
A TPM attack will depend upon individual use cases and what the attacker hopes to accomplish through the attack. But the attack remains difficult to weaponize, and turn into a general-purpose, automated attack that anyone with the tool could carry out.
First, that attacker must get the public key to the vulnerable RSA key pair. TPM public keys generally remain on the local machine, and are not used across a network, though there are cases for network use of a TPM public key. (Brook has reviewed several such cases, but none of these was with the Infineon TPM.)
Smart card attacks, especially national cards, have been analyzed elsewhere. (See references, at end.) We find no fault in those analyses. Purveyors of smart cards using vulnerable RSA key pairs have been placed on notice to respond, quickly and effectively.
We offer this analysis in the hope that defenders and incident responders will be better able to assess the relative importance of the Infineon RSA RNG vulnerability to key derivation.
Typical consumers will not likely, at least immediately, be a target of this attack. The exploit may never become sufficiently automated to make it useful for broad cybercriminal activity. Those with valuable secrets protected by a vulnerable key pair would be wise to fix or remove the issue.
If a reader feels that they might be a target, then a first line of defense will be to install and maintain endpoint protections such as the latest version of McAfee Endpoint Security (ENS) or similar protections. By keeping attackers from establishing any presence on a machine, most credible attack scenarios cannot achieve the prerequisite first step such that any local, public RSA keys can be obtained.
McAfee Drive Encryption key reprovisioning
Drive Encryption is affected only if the TPM Autoboot policy is in use. McAfee Drive Encryption customers wishing to update an Infineon TPM should follow these steps:
- Change the TPM Autoboot policy to Non-TPM Autoboot (or use Temporary Autoboot).
- Update the Infineon TPM firmware provided by your hardware vendor.
- Clear the TPM.
- Reprovision the TPM with new keys.
- Re-enable the TPM autoboot policy.
See the McAfee Service Portal for updates and detailed information.
Brook Schoenfield is Principal Engineer, Product Security Architecture and Jonathan Oulds is Senior Software Development Engineer and Product Security Champion Lead. They thank Joani Wilkinson, Senior Technical Support Engineer, for her assistance with this analysis.
References
https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx
https://docs.microsoft.com/en-us/windows-hardware/drivers/dashboard/get-a-code-signing-certificate
https://developer.apple.com/support/code-signing/
https://en.wikipedia.org/wiki/Pretty_Good_Privacy
RFC 4880 (November 2007)
RFC 4880bis in 2014
https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update
Notes
[1] First-generation MacBooks included an Infineon TPM but did not use it. See http://www.osxbook.com/book/bonus/chapter10/tpm/.
[2] Pseudorandom number generators have plenty of cryptographic problems, which is why HSM vendors build high-entropy RNG.
[3] TPM key use cases are largely confined to the machine upon which they are used, which implies that the attacker has gained a foothold on the machine to get the public key.
Stay Updated
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.
